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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The IM CN subsystem interworks with the external IP networks through the Mb reference point. 

This document details the interworking between the IM CN subsystem and external IP networks for IM service support. 
It addresses the issues of control plane interworking and, user plane interworking for specific interworking use cases. 
Clause 10 describes the IMS-Ix interface requirements in the form of Use Cases which require H.248 protocol 
procedures. Subclause 10.4 then details the additional Information Elements required to perform the specific 
procedures. 

The IP version Interworking, between IP version 4 (IETF RFC 791 [9] ) and IP version 6 (IETF RFC 2460 [10] ) 
detailed in terms of the processes and protocol mappings required in order to support both mobile originated and 
terminated calls. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[2] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[3] 3GPP TS 23.221: "Architectural requirements". 

[4] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting 

packet based services and Packet Data Networks (PDN)". 

[5] 3GPP TS 23.002: "Network architecture". 

[6] 3GPP TS 26.235: "Packet switched conversational multimedia applications; Default codecs". 

[7] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[8] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[9] IETF RFC 79 1 : "Internet Protocol" . 

[10] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification". 

[II] IETF RFC 2766: "Network Address Translation - Protocol Translation (NAT-PT)". 

[12] IETF RFC 2663: "IP Network Address Translator (NAT) Terminology and Considerations". 

[13] 3GPP TR 29.962 version 6.1.0: "Signalling interworking between the 3GPP profile of the Session 

Initiation Protocol (SIP) and non-3GPP SIP usage". 

[14] Void. 

[15] Void. 

[16] Void. 
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[17] Void. 

[18] IETF RFC 792: "Internet Control Message Protocol". 

[19] IETF RFC 2463: "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 

6". 

[20] Void. 

[21] Void. 

[22] Void. 

[23] Void. 

[24] Void. 

[25] 3GPP TS 29.238: "Interconnection Border Control Functions - Transition Gateway; H.248 Profile; 

Stage 3". 

[26] ITU-T Recommendation H.248. 1 (05): "Gateway Control Protocol: Version 3". 

[27] Void. 

[28] 3GPP TS 23.205: "Bearer-independent circuit-switched core network; Stage 2". 

[29] 3GPP TS 29.235: "Interworking between SIP-I based circuit-switched core network and other 

networks". 

[30] Void. 

[31] IETF RFC 2474: "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 

Headers". 

[32] 3GPP TS 33.328: "IMS Media Plane Security". 

[33] IETF RFC 4568: "Session Description Protocol (SDP) Security Descriptions for Media Streams". 

[34] IETF RFC 37 1 1 : "The Secure Real-time Transport Protocol (SRTP)" . 

[35] IETF RFC 5 124: "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)- 

Based Feedback (RTP/SAVPF)". 

[36] 3GPP TS 26. 1 14: "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handHng and 

interaction" . 

[37] IETF RFC 3 1 68 : "The Addition of Explicit Congestion Notification (ECN) to IP" . 

[38] IETF RFC 6679: "Explicit Congestion Notification (ECN) for RTP over UDP". 

[39] 3GPP TS 29.079: "Optimal Media Routeing within the IP Multimedia Subsystem; Stage 3". 

[40] 3GPP TS 29. 165: "Inter-IMS Network to Network Interface (NNI)". 

[41] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2". 

[42] 3GPP TS 24.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 3". 

[43] 3GPP TS 23.334: "IP Multimedia Subsystem (IMS) Application Level Gateway (IMS-ALG) - 

IMS Access Gateway (IMS-AGW) interface: Procedures descriptions". 
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Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [7] and the following 
apply: 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions 

IP multimedia session: set of multimedia senders and receivers and the data streams flowing from senders to receivers 
IP multimedia sessions are supported by the IP multimedia CN Subsystem and are enabled by IP connectivity bearers 
(e.g. GPRS as a bearer). A user may invoke concurrent IP multimedia sessions. 

MSC Server enhanced for ICS: An MSC Server that supports the network based ICS functionality. 

MSC Server enhanced for SRVCC: An MSC Server that supports the network based SRVCC functionality. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 



Mm 
Mx 

Mb 
Ix 



Reference Point between a CSCF/BGCF/IMS-ALG and an IP multimedia network. 

Reference Point between a CSCF/BGCF/MSC Server enhanced for ICS/MSC Server enhanced for 

SRVCC and IBCF. 

Reference Point defined in 3GPP TS 23.002 [5] and is IP based. 

Reference Point between IBCF and TrGW or CS-IBCF and CS-TrGW. 



3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [7] and the following apply: An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [7]. 

ATCF Access Transfer Control Function 

ATGW Access Transfer Gateway 

B2BUA Back-to-Back User Agent 

BGCF Breakout Gateway Control Function 

CS-TrGW CS (domain) TrGW 

ECN Explicit Congestion Notification 

ECN-CE ECN Congestion Experienced 

IBCF Interconnect Border Control Function 

ICS IMS CentraUzed Services 

I-CSCF Interrogating CSCF 

IMS-ALG IMS - Application Level Gateway 

ITU-T International Telecommunication Union - Telecommunication Standardization Sector 

MbolP Mb over IP 

MRFP Multimedia Resource Function Processor 

NAT/NAPT Network Address Translation / Network Address and Port Translation 

NA (P) T-PT Network Address (and Port) Translation - Protocol Translation 

OMR Optimal Media Routeing 

P-CSCF Proxy CSCF 

RTCP Real Time Control Protocol 

SCTP Stream Control Transmission Protocol 

SIP UA SIP User Agent 

UAC User Agent Client 

UAS User Agent Server 

THIG Topology Hiding Internetwork Gateway 

TrGW Translation GateWay 

WAN Wide Area Network 
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4 General 

4.1 General interworking overview 

The IM CN Subsystem interworks with SIP (IETF RFC 3261 [2] ) based IP Multimedia networks. These IP Multimedia 
networks include: 

- SIP User Agents (SIP UAs); and 

- SIP Servers. 

As such, the IM CN Subsystem has to be able to interwork to all of these above functional entities in the IP multimedia 
network, as there is a possibility that they all may be involved in an IM session. The general interworking model is 
shown in figure 1. The SIP based Multimedia networks may use IP version 4 (IETF RFC 791 [9] ) or IP version 6 
(IETF RFC 2460 [10]). 



MSC Server 
enharxed 
forlCSa 
for SRVCC 




Signaling 
Bearer 



IMCN subsystem network 



IP multimedia network 



Figure 1 : Interworking IVIodel for IIV! CN Subsystem to IP Multimedia Network 

The UE uses the CSCF in order to communicate with the external IP multimedia network entities. 

If no IP version interworking or no NAT/NAPT between different realms is required, the CSCF can communicate with 
SIP UAs in an external IP multimedia network directly. 

If no IP version interworking or no NAT/NAPT between different realms is required, the CSCF can also communicate 
with SIP proxies in an external IP multimedia network directly, which in turn can then communicate with SIP UAs. 

To provide the IP version interworking or NAT/NAPT between different realms the functions of an IMS-ALG and a 
TrGW may be inserted between the CSCF and external IP Multimedia Network by configuration. The IMS-ALG and 
the TrGW may be implemented as a part of other physical entities in the IMS. 

NOTE: Other methods to provide IP version interworking are outside the scope of this release. 



4.2 Interworking scenarios 



3GPP specifications design the IM CN subsystem elements and interfaces to exclusively support IPv6. 

3GPP TS 23.221 [3] details the interoperability scenarios that an UE may experience when interworking with an 
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external PDN. All of these IP transport layer interworking scenarios can apply to the application layer interworking 
scenarios detailed in subclause 4.2.1. 

4.2.1 UE with 3GPP SIP profile capability connecting to an external SIP 
device 

The procedures used by an UE with 3GPP SIP profile to connect to an external SIP device, which may lack 3GPP SIP 
profile capabilities, have been analysed in Release 6 within 3GPP TR 29.962 [13] and are specified in 

3GPPTS 24.229 [1]. 



5 Network characteristics 

5.1 Key characteristics of IP IVIultimedia Networks 

The Internet is a conglomeration of networks utilising a common set of protocols. IP protocols are defined in the 
relevant IETF RFCs. The networks topologies may be based on LANs (e.g. Ethernet), Point-to-Point leased lines, 
PSTN, ISDN, X.25 or WANs using switched technology (e.g. SMDS, ATM). 

IP multimedia networks provide the ability for users to invoke IP multimedia applications in order to send and receive 
(where applicable) voice and data communications. One protocol used to manage IP multimedia sessions is the Session 
Initiation Protocol (SIP) (IETF RFC 3261 [2]). 

5.2 Key characteristics of UIVITS IIVI CN Subsystem 

The UMTS IM CN subsystem uses the SIP protocol to manage IP multimedia sessions, and uses IP as the transport 
mechanism for both SIP session signalling and media transport. 

The UMTS IM CN subsystem shall support interworking with existing fixed and mobile voice and IP data networks, 
including PSTN, ISDN, Mobile and Internet. 



6 Interworking Reference IVIodel for control plane 

interworking and user plane interworking 

6.0 Reference Model 

Figure 2 details the reference architecture required to support interworking between the IM CN subsystem and IP 
networks for IM services. Figure 3 details the reference architecture required to support interworking between the IMS 
and IP SIP networks supporting IP version 4. 
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CSCF 



I 



Mm 



Mb 




NOTE: Multimedia IP networks may be connected via the Mb interface to various network entities, such as an UE 
(via an GTP Tunnel reaching to the GGSN), an MRFP, or an application server. 

Figure 2: IM CN Subsystem to IP network interworking reference Architecture without IP version 
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Figure 3: Border Control Functions 

Mm reference point: The call control protocol applied to the Mm interface between CSCF and external IP networks is 
SIP, IETF RFC 3261 [2], as detailed in 3GPP TS 24.229 [1]. SIP extension packages mandated by 3GPP are possibly 
not supported. 

Mb reference point: This interface is defined in 3GPP TS 23.002 [5] and is IP based. Further information is provided 
in 3GPP TS 29.061 [4] and 3GPP TS 26.235 [6]. 

Mx reference point: The protocol applied at the Mx reference point is specified in 3GPP TS 24.229 [1]. 

Ix reference point: The protocol applied at the Ix reference point is specified in 3GPP TS 29.238 [25]. 
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6.1 Interworking Functional Entities 

6.1.1 IBCF 

This entity provides control plane functionality to connect entities following the 3GPP profile of SIP, 3GPP TS 24.229 
[1], and external SIP entities following IETF RFC 3261 [2]. 

6.1.2 IIVIS-ALG 

IMS-ALG functionality resides in IBCF. An IMS-ALG provides the application level translation function for SIP and 
SDP in order to communicate between IPv6 and IPv4 SIP applications or, based on operator policies between different 
realms using the same IP version. The IBCF acts as a SIP B2BUA when IBCF performs IMS-ALG functionality. 

6.1.3 TrGW 

The TrGW is a NAT-PT/NAPT-PT, which uses a pool of globally unique IPv4 addresses for assignment to IPv6 nodes 
on a dynamic basis as sessions are initiated across the IP version boundaries. NAT-PT binds addresses in IPv6 network 
with addresses in IPv4 network and vice versa to provide transparent routing between the two IP domain without 
requiring any changes to end points. NAPT-PT provides additional translation of transport identifier (TCP, SCTP and 
UDP port numbers). More detailed information on the NAT-PT/NAPT-PT is given in IETF RFC 2766 [11] and IETF 
RFC 2663 [12]. 

The TrGW may provide the NAT/NAPT functionality between two disparate address realms. 

6.1 .4 Acces Transfer Control Function 

The ATCF may reside within the IBCF to support "SRVCC enhanced with ATCF" procedures as described in 3GPP TS 
23.237 [41] and 3GPP TS 24.237 [42] . In this case, the Ix reference point is used for IMS sessions that the ATCF 
decides to anchor at the ATGW to provide the following functions: 

reservation and configuration of ATGW resources for media anchoring during PS session origination or 
termination; 

reconfiguration of ATGW resources during access transfer to the CS domain; 

release of ATGW resources upon completion of the access transfer or release of the session; 

media transcoding if the media that was used prior to the access transfer is not supported by the MSC server; 

IP version interworking if different IP versions are used between the access and the remote legs; and 

indication of IP realm during allocation of transport addresses/resources (the PS and CS accesses may be 
reachable via different IP realms). 



6.1 .5 Acces Transfer GateWay 



The ATGW may reside within the TrGW to support "SRVCC enhanced with ATCF" procedures as described in 3GPP 
TS 23.237 [41] and 3GPP TS 24.237 [42]. If the IBCF supports the ATCF functionahty (see subclause 6.1.4), the IBCF 
shall select a TRGW which supports the ATGW functionality. 



7 Control plane interworking 

7.1 SIP with 3GPP Profile to Standard SIP Interworking 

3GPP TS 24.229 [1] defines the procedures, which allow a 3GPP-IMS UE to connect to a standard SIP terminal. 
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7.2 Additional interworking of protocols associated with services 

There is no impact beyond that specified in subclause 7. 1 provided the necessary SIP extensions are supported on both 
sides of the interworking point. 

Based on operator policy and/or service level agreements the interworking of services may be restricted. 

Additional information related to interworking with services is provided in 3GPP TS 29.165 [40]. 



8 User Plane Interworking 

8.1 Overview 

The present specification addresses user plane interworking between codec types used for either speech or video. 
Codecs used for conversational services in the PS domain are as defined in 3GPP TS 26.235 [6] and 3GPP TS 26.114 
[36]. 

8.2 Void 

8.3 Void 



9 IMS-ALG and TrGW functionality for NAPT and IP 

Version Interworking 

9.1 Control plane interworking 
9.1.1 Session Set-up 

9.1.1.0 General 

The procedure described in clause 9.1.1 applies both for an SDP offer received from the external network and received 
from the IMS. 

If different IP versions are used in the external network and the IMS, the TrGW shall provide IP version interworking of 
the user plane. Otherwise, the TrGW provides NAPT functionality. 

9.1 .1 .1 Receipt of the first SDP offer 

At the receipt of the first SDP offer from an offering network A the IMS-ALG shall: 

Request the TrGW to allocate a termination towards an answering network B and provide IP address(es) and port 
number(s) from its pool for this termination. 

When the IMS-ALG has received the requested information from the TrGW, the IMS-ALG shall include the 
address(es) and port number(s) in a new offer, and sent this offer toward the network B. The IMS-ALG shall create a 
SIP message in accordance with the rules for the IMS-ALG described in subclause 9.1.4 with the following 
clarification: 

The IP address(es) and port number(s) received from the TrGW for the termination towards network B shall 
replace the IP address(es) and port number(s) in the SDP. 
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9.1 .1 .2 Receipt of the first SDP answer 

At the receipt of the first SDP answer from network B the IMS-ALG shall: 

Provide to the TrGW the address(es) and port number(s) as received in the c-line(s) and m-line(s) in the SDP 
answer as destinations for the termination towards answering network B; 

Request the TrGW to allocate a termination towards the offering network A and provide IP address(es) and port 
number(s) from its pool for this termination, and provide the IP address and port number received in the first 
SDP offer from network A as destination for this termination, unless this step has already been executed earlier, 
e.g. at the receipt of the SDP offer; and 

Requests the TrGW to bind the termination towards network A and the the termination towards network B to 
enable the routing of user plane traffic towards the IPv4 SIP network through the TrGW. 

NOTE: The binding request will be combined with the request to create terminations in the H.248 protocol 

When the IMS-ALG has received the requested information, the IMS-ALG shall send an SDP answer to the network A. 
The IMS-ALG shall create the SIP message in accordance with the rules for the IMS-ALG described in subclause 9.1.4 
with the following clarification: 

The IP address(es) and port number(s) received from the TrGW for the termination towards network A shall 
replace the received IP address(es) and port number(s) in the SDP. 

9.1.2 Void 

9.1 .3 Change of connection information 

After the dialog is established it is possible for both ends of the session to change the connection data for the session. 
When the IMS-ALG/TrGW receives a SDP offer/answer where port number(s) or IP address(es) is included., there are 
four different possibilities: 

1) IP address(es) or/and port number(s) have been added. In this case additional binding(s) shall be provided by the 

IMS-ALG/TrGW as detailed for the first SDP offer in the subclauses above; 

2) IP address(es) or/and port number(s) have been deleted. In this case binding(s) shall be made free by the IMS- 

ALG/TrGW; 

3) IP address(es) and port number(s) have been reassigned of the users. In this case the binding(s) shall reflect the 

reassignment; and 

4) No change has been made to the IP address(es) and port number(s). In this case no change shall be made to the 

existing binding(s). 

9.1 .4 Interworking of SIP messages 

The IMS-ALG behaves as a SIP B2BUA when interworking SIP messages. The IMS-ALG shall forward all SIP 
messages transparently with respect to all methods, result codes, headers and attachments except as follows: 

- The IMS-ALG modifies SDP according to subclauses 9.1.1, 9.1.2 and 9.1.3; 

When forwarding an incoming SIP request, the IMS-ALG should perform UAC procedures towards the intended 
target according to IETF RFC 3261 [2], by modifying those headers necessary to ensure that all transactions 
within the dialog pass through the IMS-ALG; 

When forwarding an incoming SIP response, the IMS-ALG should perform UAS procedures towards the 
originator of the corresponding request according to IETF RFC 3261 [2], by modifying those headers necessary 
to ensure that all transactions within the dialog pass through the IMS-ALG; 

The IMS-ALG may perform any appropriate error recovery procedures in the event that an incoming message 
contains errors inconsistent with the forwarding procedures above; and 
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The IBCF can perform screening of SIP request and SIP responses based on local policy as described in 
subclause 5.10.6 of 3GPP TS 24.229 [1]. 

At the receipt of a SIP BYE request, SIP CANCEL request or non-200 SIP final response, the IMS-ALG shall release 
the session and request the TrGW to release the bindings established for the session. 

9.2 User plane transport 

9.2.1 Payload transport 

The TrGW shall use the established bindings described in subclause 9. 1 to transport the messages between the network 
A and the network B in the following way. 

At the receipt of a payload message the TrGW shall: 

replace the received destination IP address(es) and port number(s) in the payload message with the 
corresponding IP address(es) and port number(s) that have been signalled by the IBCF; and 

replace the received source IPaddress(es) and port number(s) in the payload message with the corresponding 
IPaddress(es) and port number(s) the TrGW allocated at its own terminations. 

9.2.2 IP header interworking 



9.2.2.1 



IPv4 to IPv6 



When the TrGW receives an IPv4 message the following codings shall be set in the IPv6 headers of the message sent to 
the IPv6 network. 

If the DP bit is set and the packet is not a fragment (i.e., the MP flag is not set and the Fragment Offset is zero) 
The IPv6 headers shall be set as described in table 1 ; 

If the DP bit is not set or the packet is a fragment the IPv6 headers shall be set as described in table 2. 
Table 1 : Derivation of IPv6 Header from IPv4 header (no fragmentation) 



IPv6 field 


Value 


Version 


6 


Traffic Class: 


The default behaviour is that the 
value of the IPv6 field Traffic Class 
field is the value of the IPv4 Type Of 
Service field (all 8 bits are copied). 
An implementation of a TrGW 
should also provide the ability to 
ignore the value of the IPv4 Type of 
Service and always set the IPv6 
traffic class field to zero. 


Flow label 


The Ipv6 Flow Label Field is set to 
(all zero bits). 


Payload Length 


The IPv6 Payload Length field value 
is the IPv4 Total length field value 
minus the size of the IPv4 header 
and IPv4 options field length, if 
present. 
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Next Header 


The Ipv6 Next Header value is 
copied from IPv4 Protocol field 


HopLimit: 


The IPv6 Hop Limit value is The 
value of IPv4 field Time To Live 
minus 1. 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 



Table 2: Derivation of IPv6 Header from IPv4 Header (fragmentation) 



IPv6 field 


Value 


Version 


6 


Traffic Class: 


The default behaviour is that the 
value of the IPv6 field Traffic Class 
field is the value of the IPv4 Type Of 
Service field (all 8 bits are copied). 
An implementation of a TrGW 
should also provide the ability to 
ignore the value of the IPv4 Type of 
Service and always set the IPv6 
traffic class field to zero. 


Flow label 


The Ipv6 Flow Label Field is set to 
(all zero bits). 


Payload Length 


The IPv6 Payload Length field value 
is the IPv4 Total length field value 
plus 8 for the fragment header 
minus the size of the IPv4 header 
and IPv4 options field length, if 
present. 


Next Header 


The IPv6 Next header field is set to 
Fragment header (44). 


Hop Limit: 


The IPv6 Hop Limit value is The 
value of IPv4 field Time To Live 
minus 1. 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1 . 


Fragments headers 

a) next header 

b) fragment Offset 

c) IVIore fragment bit 

d) Identification 


Copied from IPv4 Protocol field. 
Copied from the IPv4 Fragment 
offset field. 

Copied from the value of the more 
fragment bit in the IPv4 flags field. 
The value of this field should be 
mapped from the triple of the source 
address, destination address and 
IPv4 identification field of the 
incoming packet/fragments to a 
unique value for the source and 
destination address of the outgoing 
IPv6 packet/fragments. 



9.2.2.2 



Abnormal cases 



If IPv4 options are present in the IPv4 packet, they should be ignored i.e., there is no attempt to translate them. 
However, if an unexpired source route option is present then the packet shall instead be discarded, and an ICMPv4 
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"destination unreachable/source route failed" Type 3/Code 5 error message shall be returned to the sender as defined in 
IETF RFC 792 [16]. 

When a translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero the 
translator should drop the packet and generate a system management event specifying at least the IP addresses and port 
numbers in the packet. When the translator receives fragments other than the first it should silently drop the packet 
since there is no port information to log. 

When a translator receives an unfragmented UDP IPv4 packet and the checksum field is zero the translator shall 
compute the missing UDP checksum as part of translating the packet. Also, the translator should maintain a counter of 
how many UDP checksums are generated in this manner. 



9.2.2.3 



IPv6 to IPv4 



When the TrGW receives an IPv6 message the following codings shall be set in the IPv4 headers of the message sent to 
the IPv4 network. 

If there is no IPv6 fragment header, the IPv4 header fields shall be set as described in Table 3; 

if there is an IPv6 fragment header, the IPv4 header fields shall be set as described in Table 4. 

Table 3: Derivation of IPv4 Header from IPv6 Header (no fragmentation) 



IPv4 field 


Value 


Version 


4 


Internet header length 


5 (No IPv4 options) 


Type of Service 


The default behaviour is that the 
value of the IPv4 field Type of 
service field is the value of the IPv6 
Traffic class field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv6 
Traffic Class and always set the 
IPv4 Type of Service field to zero. 


Total length 


The IPv4 Total Length field value is 
the IPv6 Payload length value plus 
the size of the IPv4 headers. 


Identification 


All bits are set to zero. 


Flags 


The more fragment flag is set to 
zero. The Don"t fragment flag is set 
to one. 


Fragment offset 


Set to zero. 


Time to live (TTL) 


The value of the field shall be set to 
the received IPv6 Hop Limit field 
value minus 1. 


Protocol 


The IPv4 field Protocol shall be set 
to the value of IPv6 field The next 
header value. 


Header checksum 


Computed once the IPv4 header 
has been created. 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 
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Table 4: Derivation of IPv4 Header from IPv6 Header (fragmentation) 



IPv4 field 


Value 


Version 


4 


Internet header length 


5 (No IPv4 options) 


Type of Service and Precedence: 


The default behaviour is that the 
value of the IPv4 field Type of 
service field is the value of the IPv6 
Traffic class field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv6 
Traffic Class and always set the 
IPv4 Type of Service field to zero. 


Total length 


The IPv4 Total Length field value is 
the IPv6 Payload length value plus 
the size of the IPv4 headers minus 
8 for the Fragment header. 


Identification 


The value of this field should be 
mapped from the triple of the source 
address, destination address and 
IPv6 fragmentation header field 
"identification" of the incoming 
packet/fragments to a unique value 
for the source and destination 
address of the outgoing IPv4 
packet/fragments. 


Flags 


The IPv4 More Fragments flag is 
copied from the IPv6 M flag in the 
IPv6 Fragment header the IPv4. 
The Don't Fragments flag is set to 
zero allowing this packet to be 
fragmented by IPv4 routers. 


Time to live (TTL) 


The value of the field shall be set to 
the received IPv6 Hop Limit field 
value minus 1. 


Protocol 


The IPv4 field Protocol shall be set 
to the value of IPv6 field The next 
header value. 


Header checksum 


Computed once the IPv4 header 
has been created. 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 



9.2.2.4 



Abnormal cases 



If any of an IPv6 hop-by-hop options header, destination options header, or routing header with the Segments Left field 
equal to zero are present in the IPv6 packet, they are ignored i.e., there is no attempt to translate them. However, the 
Total Length field and the Protocol field shall be adjusted to "skip" these extension headers. 

If a routing header with a non-zero Segments Left field is present then the packet shall be translated, and an ICMPv6 
"parameter problem/ erroneous header field encountered" Type 4/Code error message as defined in IETF RFC 2463 
[17], with the Pointer field indicating the first byte of the Segments Left field should be returned to the sender. 

9.2.3 Fragmentation 

If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the TrGW shall prior to 
transferring it in the IPv6 network: 

- Add the fragment header to the message; and 
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fragment the IPv4 packets so that their length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 
for the IPv6 header and 8 for the Fragment header). 

9.2.4 Abnormal cases 

As a part of decrementing the Time To Live /Hop Limit value and the TrGW discovers that the zero value is reached 
the TrGW shall send an ICMPv4/ICMPv6 message with the error "time to live exceeded in transit" type 1 1 code as 
defined in IETF RFC 792 [16] and "hop limit exceeded in transit" type 3 code as defined in IETF RFC 2463 [19]. 



10 



IBCF - TrGW Interactions 



10.1 Overview 

10.1.1 General 

The present specification describes Ix signalling procedures and their interaction with SIP signalhng in the control 
plane, and with user plane procedures. Each scenario or "use case" is described in a separate subclause within subclause 
10.2. 3GPP TS 29.238 [25] maps these signalling procedures to H.248 messages and defines the required H.248 profile 
(which provides details of used packages and parameters). 

10.1.2 Network model 

Figure 10.1.2.1 shows the network model. The broken line represents the call control signalling. The dotted line 
represents the user plane. The IBCF uses one context with two terminations in the TrGW. 




Figure 10.1.2.1: Network model 

Example Call Flow 
10.1.3.1 Basic Procedures 

10.1.3.1.1 Call Establishment 

Figure 10.1.3.1.1.1 depicts the signalling flow for a call setup either from or toward an external network. 
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5. H.248 ADD resp. 
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LAddr=IPlo, LPort=Plo) 



A 



6. IVIodify SDP offer 



9. H.248 IVIOD req 
(C=CI,T=TI, 
RAddr=IPla, RPort=Pla) 



1 0. Configure Outgoing Termination T1 



11. H.248 IVIOD Resp 
C=C1,T=T1) 



12. H.248 ADD req 

C= CI, T= ?, LAddr=?, LPort=?, 

RAddr=IP2o, RPort=P20) 



1 3. Create incoming Termination T2 



14. H.248 ADD Resp 
C=C1,T=T2, 
LAddr=IP2a, LPort=P2a, 
RAddr=IPla, RPort=Pla) 



.lSDPoffer_(IP20j_P2p) 



15. Modify SDP answer 



Reserve 
TrGW 
Connection 
Point (, 
Change 
Through- 
Connection) 



Configure 
TrGW 
Connection 
Point (, 
Change 
Through- 
Connection) 



Reserve 
And 

Configure 
TrGW 
Connection 
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Change 
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16. SDP answer(lp2a, P2a) 



1 . The IBCF receives an SDP offer In SIP signalling. 

2. The IBCF detects that one of the CS-TrGW functions is required, e.g. NAPT/NAT. 

3. The IBCF sends a H.248 ADD command to create the outgoing termination and to request resources to 
execute TrGW function. 

4. The TrGW creates the outgoing termination. 

5. The TrGW replies to IBCF with a H.248 Add reply command and provides the local address and port of the 
outgoing termination. 

6. The IBCF replaces the IP address inside the SDP using the information coming from TrGW. 

7. SDP offer is sent to the network at the outgoing side. 

8. SDP answer is received by IBCF. 
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9. The IBCF sends a H.248 MOD command to configure the outgoing termination with address and port 
information received in the SDP answer. 

10. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 MOD reply command. 

12. The IBCF sends a H.248 ADD command to create the incoming termination and to request resources to 
execute TrGW function. 

1 3. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 Add reply command and provides the local address and port of 
the incoming termination. 

NOTE 1 : Steps 1 2 to 14 may also be executed after step 2. 

15. The IBCF replaces the IP address inside the SDP using the information coming from TrGW. 

16. SDP answer is sent to the network at the incoming side. 

Figure 10.1.3.1.1.1: IBCF and TrGW interaction at Call establishment. 

When creating the termination towards the IMS network or towards external networks, the IBCF may also indicate that 
the IP Interface Type is "MboIP". 

NOTE : Other values may be indicated by a CS-IBCF, as detailed in 3GPP TS 29.235 [29]. 

The IP Interface Type allows the TrGW to collect statistics per interface type associated with the RTP bearer 
termination. The provision of these statistics is outside of the scope of this specification. 
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10.1.3.1.2 Call Release 

Figure 10.1.3.1.2.1 depicts the signalling flow for a call release. 



TrGW 



2. H.248SUBreq 
C=C1,T=T1) 



3. Destroy outgoing termination T1 



5. H.248SUBreq 
C=C1,T=T2) 



6. Destroy incoming termination T2 



IBCF 



4. H.248 SUB reap. 
(C=C1,T=T1) 



7. H.248 SUB resp. 

(C=C1,T=T2) 



. 1 Event_causing_release 

Release 

TrGW 

Termination 



Release 

TrGW 

Termination 



1 . The IBCF identifies that the call is to be release. Typically this will be by the receipt of a SIP BYE request. 

2. The IBCF sends a H.248 SUB command to release the outgoing termination. 

3. The TrGW destroys the outgoing termination. 

4. The TrGW replies to IBCF with a H.248 SUB reply command. 

5. The IBCF sends a H.248 SUB command to release the incoming termination. 

6. The TrGW destroys the incoming termination. 

7. The TrGW replies to IBCF with a H.248 SUB reply command. 

NOTE 1 : Steps 5 to 7 may also be executed before steps 2 to 4 or in parallel with steps 2 to 4. 

NOTE 2: Rather than releasing the two terminations separately, the IBCF may request the TrGW to release both 
terminations in a single request. 

Figure 10.1.3.1.2.1 : IBCF and TrGW interaction at Call release 

10.2 Main Functions supported at the Ix Interface 
10.2.0 Introduction 

The following functions shall be supported by the TrGW: 
Gate Management including: 
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o Opening/closing of gates; 

o Remote source address filtering; and 

o Remote source port filtering; 
QoS packet marking (differentiated services); 
NAPT and IP Version Interworking; 
Bandwidth policing; 
Hanging termination detection; 
IP Realm Indication; 
Media Control; and 
Through-Connection. 
Additionally, the following functions may be supported by the TrGW: 
Resource allocation per flow; 
Media Inactivity Detection; 
IP Realm Availability; 
Optimal Media Routeing; 
Explicit Congestion Notification support ; 
Emergency Call; 

IMS end-to-end media plane security; and 
Access Transfer procedures with media anchored in ATGW. 

1 0.2.1 NAPT and IP version interworking 

NAPT and IP version interworking is documented in clause 9. 

The IP Address and port conversion is configured by the standard Ix interactions at call setup depicted in figure 
10.1.3.1.1.1. 

IP address and port conversion is mandatory every time a TrGW is inserted into the path for any reason to guarantee 
that all IP packets are routed through this entity. 

10.2.2 Gate Management 

The procedures in subclause A.7.1.2.2.3 of 3GPP TS 29.235 [29] are applicable. 

10.2.3 RTCP Handling 

The procedures in subclause A.7.1.2.2.7 of 3GPP TS 29.235 [29] are applicable. 

10.2.4 IP Realm Indication 

Whenever requesting a new IP media-path (i.e. creation of IP bearer terminations), the TrGW may indicate the 
correspondent IP realm/domain to the TrGW. The TrGW shall assign the IP termination in the IP realm indicated. The 
same IP realm shall be applied to all media streams associated with the termination. The IP realm identifier shall not be 
changed after the initial assignment. 
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A default IP realm may be configured such that if the TrGW has not received the IP realm identifier and the TrGW 
supports multiple IP realms then the default IP realm shall be used. 

10.2.5 Media Control 

The transcoding functionality, where the TrGW processes and possibly converts application / media data (like e.g. RTP 
payload) is optional for the TrGW and IBCF to support. 

The IBCF shall determine the TrGW transcoding capability through provisioning and MGW selection, outside the 
scope of this specification. 

IBCF procedures to offer transcoding in SIP/SDP signalHng are described in 3GPP TS 23.228 [8] and in 3GPP TS 
24.229 [1]. The IBCF shall only apply those transcoding procedures if an attached TrGW supports transcoding. For 
media with "RTP/SAVP" (see IETF RFC 371 1 [34]) or "RTP/SAVPF" (see IETF RFC 5124 [35]) as transport protocol, 
the IBCF shall not offer or apply transcoding. 

If the IBCF and available TrGW support transcoding, the IBCF may add codecs to a SDP offer within a SIP request. 

If the IBCF and available TrGW do not support transcoding, or if the IBCF chooses not to offer transcoding, the IBCF 
shall pass SDP offers without adding codecs to the SDP offer and the IBCF shall pass SDP answers without 
modification to the contained codecs. 

If the IBCF does not offer or apply transcoding procedures (as described above) but inserts the TrGW for any other 
reason, the IBCF shall either not signal media related information to the TrGW, or it shall signal the same media related 
information for all interconnected terminations (i.e. identical media configurations for the two connected H.248 stream 
endpoints). 

If the IBCF does not offer or apply transcoding but signals media attributes to a TrGW that does not support 
transcoding without having seized the peer termination (see figure 10.2.5.3, Step 3) the TrGW shall accept this request 
even though it cannot reserve any transcoding resources related to this media. When the peer termination is seized and 
configured it shall be configured with the same media related sub-fields in the media descriptor as for the first 
termination. If the selected codec is not the same as the codec configured at the first termination then this termination 
shall be modified before the peer termination is seized. 

NOTE 1 : The signalling of such codec related information by an IBCF to a TrGW not supporting transcoding is an 
implementation decision. 

NOTE 2: A TrGW not supporting transcoding can use such codec related information to learn that RTCP ports 
need to be reserved, and to derive information about packet size and frequency useful for internal 
resource reservation. 

If the IBCF and available TrGW support transcoding and the IBCF includes in a SDP offer additional codecs, the 
following procedures apply: 

The IBCF may seize a termination towards the terminating user, using the "Reserve TrGW Connection Point" 
procedure before sending an SDP offer with added codecs to the terminating user. The IBCF may signal media 
related information to the TrGW or omit media when adding the IP termination at this stage. 

NOTE 3: The signalling of media related information to a MGW requires that it reserve the indicated resources 
before returning a positive response to the H.248 command, by omitting media related information the 
TrGW does not need to reserve any associated resources at this stage. 

When the IBCF receives the SDP answer from the terminating user, the IBCF shall check if any of the codecs 
offered by the originating side are contained in the answer. 

If only the codecs inserted by the IBCF are contained in the answer, the IBCF shall configure the TrGW to 
transcode. If it previously performed a "Reserve TrGW Connection Point" procedure it shall configure the 
TrGW using the "Configure TrGW Connection Point" procedure towards the termination on the terminating user 
side by supplying the media returned in the answer from the terminating user, otherwise it shall perform a 
"Reserve and Configure TrGW Connection Point" procedure. Within those procedures, the IBCF shall supply 
the media returned in the answer from the terminating user. If the IBCF seized the termination only at this point 
in time, it shall send the IP address and port information received from the TrGW in the acknowledment to the 
"Reserve and Configure TrGW Connection Point" procedure towards the terminating user in a new SDP offer. 
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The IBCF shall perform the "Reserve and Configure TrGW Connection Point" procedure towards the 
termination on the originating user side, supplying the preferred media offered by the originating side. 

If the returned SDP contains media offered by the originating user no transcoding at the TrGW is required. If the 
IBCF previously performed the "Reserve TrGW Connection Point" procedure the IBCF shall configure the 
TrGW accordingly by either either supplying the same media related information for all interconnected 
terminations or by omitting the media related information. 

Some basic use cases are depicted in figures 10.2.5.1, 10.2.5.2, and 10.2.5.3. 
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1 3. Create incoming Termination T2 



14. H.248 ADD Resp 
C= CI, T= T2, 
LAddr=IP2a, LPort=P2a, 
RAddr=IP2o, RPort=P2o) 



Configure 
TrGW 
Connection 
Point 



Reserve 

And 

Configure 
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Connection 
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15. IVIodify SDP answer 



16. SDP answer(lp2a, P2a, 
. codecj ]_ ^ 



1 . The IBCF receives an SDP offer in SIP signalling. 

2. The IBCF adds additional codecs to the subsequent SDP offer, giving priority to those offered by the 
preceding node/network. 

3. In this example the IBCF seizes a TrGW prior to sending the new SDP offer; as this scenario is preparing 
for a possible transcoding in the TrGW then a TrGW supporting media shall be seized. The IBCF sends a 
H.248 ADD request command to create the outgoing termination and to request IP resources to execute 
TrGW function. As no media transcoding is yet known to be needed this may be indicated by omitting 
media related sub-fields in the media descriptor (i.e.signalling "-"). Alternatively the preferred codec (e.g. 
codec 1 ) may be signalled in order to reserve this resource in the event that transcoding was required. 

4. The TrGW creates the outgoing termination. 
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5. The TrGW replies to IBCF with a H.248 ADD reply command and provides the local address and port of 
the outgoing termination. 

6. The IBCF replaces the IP address inside the SDR offer using the information coming from TrGW 

7. The IBCF forwards the new SDR offer to the succeeding node. 

8. The SDR answer is received by IBCF. In this example the coded received in the original SDR offer in 
step1 has been selected by the succeeding network/terminating UE and the IBCF determines that 
transcoding is not required. 

9. The IBCF sends a H.248 MOD request command to configure the outgoing termination with address and 
port information received in the SDR answer. As no media transcoding is needed this may be indicated by 
omitting media related sub-fields in the media descriptor (i.e. signalling "-"). Alternatively the selected 
codec (codec 1) may be signalled. 

1 0. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 MOD reply command. 

12. The IBCF sends a H.248 ADD request command to create the incoming termination to configure this 
termination with remote address and port information and to request resources to execute TrGW function. 
As no media transcoding is needed this may be indicated by omitting media related sub-fields in the media 
descriptor (i.e. signalling "-"). Alternatively the selected codec received in step 8 (Codec 1) may be 
signalled. 

1 3. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 ADD reply command and provides the local address and port 
of the incoming termination. 

15. The IBCF replaces the IP address inside the SDR using the information coming from TrGW. 

16. The SDR answer is sent to the network at the incoming side. 

Figure 10.2.5.1 : IBCF and TrGW interaction when the IBCF offers additional codecs but no 
transcoding is required, and the TrGW is seized in advance. 
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6. IVIodify SDP offer 



9. H.248 IVIOD req 
(C=C1,T=T1, 
RAddr=IPla, RPort=Pla, 
Local Resources= codec3 
Remote Resources= codec3) 



1 0. Configure Outgoing Termination T1 



11. H.248 IVIOD Resp 
C=C1,T=T1) 
► 

12. H.248 ADD req 

C= CI, T= ?, LAddr=?, LPort=?, 
RAddr=IP2o, RPort=P2o, 
Local Resources=codecl orcodec2, 
Remote Resources=codecl or codec: 



1 3. Create incoming Termination T2 



14. H.248 ADD Resp 
C= CI, T= T2, 
LAddr=IP2a, LPort=P2a, 
RAddr=IP2o, RPort=P2o) 
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TrGW 
Connection 
Point 
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Configure 

TrGW 
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15. IVIodify SDP answer 



16. SDP answer(lp2a, P2a, 
. codsci, or_codec_2j_ _^ 



1 . The IBCF receives an SDP offer in SIP signalling. 

2. Tlie IBCF adds additional codecs to the subsequent SDP offer, giving priority to those offered by the 
preceding node/network. 

3. In this example the IBCF seizes a TrGW prior to sending the new SDP offer; as this scenario is preparing 
for a possible transcoding in the TrGW then a TrGW supporting media shall be seized. The IBCF sends a 
H.248 ADD request command to create the outgoing termination and to request IP resources to execute 
TrGW function. As no media transcoding is yet l<nown to be needed this may be indicated by omitting 
media related sub-fields in the media descriptor (i.e. signalling "-"). Alternatively the preferred codec (e.g. 
Codec 1 ) may be signalled in order to reserve this resource in the event that transcoding was required. 

4. The TrGW creates the outgoing termination. 
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5. The TrGW replies to IBCF with a H.248 ADD reply command and provides the local address and port of 
the outgoing termination. 

6. The IBCF replaces the IP address inside the SDR offer using the information coming from TrGW. 

7. The IBCF forwards the new SDR offer to the succeeding node. 

8. The SDR answer is received by IBCF. In this example the codec 3 added by the IBCF to the SDR offer has 
been selected. Transcoding is therefore required. 

9. The IBCF sends a H.248 MOD request command to configure the outgoing termination with address and 
port information received in the SDR answer and the selected media attibutes (codec 3). 

10. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 MOD reply command. 

12. The IBCF sends a H.248 ADD request command to create the incoming termination to configure this 
termination with remote address and port information and to request resources to execute TrGW function. 
As media transcoding is required it indicates this explicitly with a codec selected by the IBCF for the 
incoming termination from the offered codec(s) received in slept . 

1 3. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 ADD reply command and provides the local address and port 
of the incoming termination. 

15. The IBCF replaces the IP address inside the SDR using the information coming from TrGW and replaces 
the codec with the codec it selected for the incoming termination. 

16. The SDR answer is sent to the network at the incoming side. 

Figure 10.2.5.2: IBCF and TrGW interaction when IBCF offers additional codecs and transcoding is 

required, and the TrGW is seized in advance. 
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. codecj ]_ ^ 



1 . The IBGF receives an SDP offer in SIP signalling. 

2. Tlie IBGF requires a TrGW for another use case but does not offer transcoding. 

3. The IBGF sends a H.248 ADD request command to create the outgoing termination and to request IP 
resources to execute TrGW function. As no media transcoding is required this may be indicated by 
signalling "-". Alternatively any codec (e.g. codec 1 ) can be signalled. If the IBGF selects a TrGW that does 
not support transcoding, the IBGF may signal media related sub-fields in the media descriptor to the TrGW 
if the TrGW supports media encoding. The TrGW shall accept the ADD request even though it cannot 
reserve any transcoding resources for the indicated media. 

4. The TrGW creates the outgoing termination. 



ETSI 



3GPP TS 29.1 62 version 1 0.7.0 Release 1 31 ETSI TS 1 29 1 62 VI 0.7.0 (201 3-01 ) 

5. The TrGW replies to IBCF with a H.248 ADD reply command and provides the local address and port of 
the outgoing termination. 

6. The IBCF replaces the IP address inside the SDP using the information coming from TrGW. 

7. The IBCF forwards the new offer to the succeeding node. 

8. The SDP answer is received by IBCF. In this example the codec 1 received in the original SDP offer in 
step 1 has been selected. 

9. The IBCF sends a H.248 MOD request command to configure the outgoing termination with address and 
port information. As no media transcoding is needed this may be indicated by signalling "-" .Alternatively 
the selected codec (codec 1) can be signalled. 

10. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 MOD reply command. 

12. The IBCF sends a H.248 ADD command to create the incoming termination to configure this termination 
with remote address and port information and to request resources to execute TrGW function. As no 
media transcoding is needed this may be indicated by signalling "-" .Alternatively media related sub-fields 
in the media descriptor for the codec indicated to the incoming termination may be signalled (e.g. the 
selected codec received in step 8 (codec 1). 

1 3. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 ADD reply command and provides the local address and port 
of the incoming termination. 

15. The IBCF replaces the IP address inside the SDP answer using the information coming from TrGW. 

1 6. The SDP answer is sent to the networl< at the incoming side. 

Figure 10.2.5.3: IBCF and TrGW interaction when IBCF does not offer transcoding 

10.2.6 Media Inactivity Detection 

The procedures in subclause A.7.1.2.2.6 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.7 QoS Packet Marking (differentiated services) 

The procedures in subclause A.7.1.2.2.4 of 3GPP TS 29.235 [29] are applicable. 

Those procedures relate to Diffserv code point marking as described in IETF RFC 2474 [31] 

10.2.8 Hanging Termination Detection 

The procedures in subclause A.7.1.2.2.2 of 3GPP TS 29.235 [29] are applicable. 

10.2.9 Bandwidtin Policing 

The procedures in subclause A.7.1.2.2.8 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.1 IMS end-to-end media plane security 

An IBCF and a TrGW may support the end-to-end IMS media plane security as specified in 3GPP TS 33.328 [32]. If 
supported, the IBCF shall use the following procedures. 

If the IBCF receives SDP containing media lines with "RTP/SAVP" (see IETF RFC 3711 [34]) or "RTP/SAVPF" (see 
IETF RFC 5124 [35]) as transport protocol, the IBCF shall: 

forward the SDP with unmodified transport protocol for those media lines; 

apply the procedures to not offer or apply transcoding defined in subclause 10.2.5; and 

- provide "RTP/SAVP" or "RTP/SAVPF", as received in the SDP, to the TrGW as transport protocol for all 
related terminations, and not provide media related information to these terminations, to configure the TrGW to 
pass media and possibly associated RTCP control flows and not to reserve any resources. 
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NOTE: RTP/SAVP or SAVPF are provided to the TrGW even though it does not reserve any resources for this as 
such, but this is needed in order to allocate dual ports to support RTCP flows. These are also controlled as 
described in subclause 10.2.3. For "RTP/SAVP" or "RTP/SAVPF", RTCP will be encrypted and can not 
be interpreted by the TrGW. Media information is also meaningless as encryption will modify the 
properties of the media streams. 

If the IBCF receives SDP containing SDES SDP attribute(s) according to IETF RFC 4568 [33], IBCF shall forward the 
SDP with unmodified SDES SDP attribute(s), but shall not provide the SDES SDP attribute(s) to the TrGW. 

10.2.11 Through-Connection 

The procedures in subclause A.7.1.2.2.9 of 3GPP TS 29.235 [29] are applicable. 

10.2.12 Emergency Call 

The procedures in subclause A.7. 1 .2.2. 10 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.1 3 Explicit Congestion Notification support 

10.2.13.1 General 

An IBCF and TrGW may support Multimedia Telephony using Explicit Congestion Notification (ECN) according to 
IETF RFC 3168 [37], and may act as an ECN endpoint to enable ECN with a local ECN-capable terminal within a local 
network that properly handles ECN-marked packets. 

1 0.2.1 3.2 Incoming SDP offer with ECN 

If the IBCF receives an SDP offer containing the "a=ecn-capable-rtp" attribute (see IETF RFC 6679 [38]), then if all of 
the following statements are true: 

a) the IBCF supports ECN according to 3GPP TS 26.114 [36]; 

b) the TrGW supports ECN according to 3GPP TS 26.1 14 [36]; 

c) the IBCF knows (via configuration) that the succeeding network supports ECN according to 3GPP TS 26.1 14 
[36]; and 

d) the IBCF does not insert any transcoding; 

then the IBCF shall: 

if the "ecn-capable-rtp" attribute includes both the "ice" initiation method and other initiation methods, remove 
the "ice" initiation method from the "ecn-capable-rtp" attribute and forward the attribute with this modification 
in the outgoing SDP offer; 

if the "ecn-capable-rtp" attribute only includes the "ice" initiation method, remove the "ecn-capable-rtp" 
attribute, any "rtcp-fb" attribute with the "nack" feedback parameter and the "ecn" feedback parameter value, and 
any "ecn-sum" parameter within a "rtcp-xr" attribute from the outgoing SDP offer; 

if the "ecn-capable-rtp" attribute did not includes the "ice" initialisation method, forward the unmodified "ecn- 
capable-rtp" attribute within the outgoing SDP offer; and 

if the IBCF includes the "ecn-capable-rtp" attribute within the outgoing SDP offer, forward the SDP offer 
containing ECN parameters to the succeeding network. 

Otherwise the IBCF shall remove the "ecn-capable-rtp" attribute, any "rtcp-fb" attribute with the "nack" feedback 
parameter and the "ecn" feedback parameter value, and any "ecn-sum" parameter within an "rtcp-xr" attribute from the 
outgoing SDP offer. 

If the IBCF forwarded the SDP offer containing the "a=ecn-capable-rtp" attribute and receives an SDP answer also 
containing the "a=ecn-capable-rtp" attribute (the reception of the attribute indicates a successful ECN negotiation) then 
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the IBCF shall forward the SDP answer to its preceding node and shall indicate to the TrGW that it shall transfer ECN 
bits in IP header transparently. 

If the IBCF forwarded the SDP offer containing the "a=ecn-capable-rtp" attribute and receives an SDP answer without 
the "a=ecn-capable-rtp" attribute and the TrGW supports at least some of the initialisation methods within the "a=ecn- 
capable-rtp" attribute in the previously received SDP offer, 

NOTE 1: Only the "leap" initialisation method is supported over the Ix interface in this release. 

the IBCF shall: 

act as an end point for ECN; 

select an initialisation method supported by the TrGW; 

determine if application specific feedback or ECN feedback messages shall be used, taking into account whether 
the TrGW supports ECN feedback messages, and the negotiation procedures in 3GPP TS 26. 1 14 [36]; 

determine if ECN XR summary reports can be used, taking into account whether they are supported at the 
TrGW, and the negotiation procedures in 3GPP TS 26.1 14 [36]; 

send the SDP answer according to 3GPP TS 26. 114 [36] and the capabilities of the TrGW, containing the ECN 
attribute "a=ecn-capable-rtp"; and 

indicate to the TrGW that it shall apply the ECN procedures (according to 3GPP TS 26. 1 14 [36]) and act as an 
ECT endpoint. 

If the IBCF receives an SDP offer containing the "a=ecn-capable-rtp" attribute and bullets a) and b) above are satisfied 
but if bullet c) or d) or both are not met then the IBCF shall remove ECN related attributes before forwarding the SDP 
offer. If the TrGW supports at least some of the initialisation methods offered within the "a=ecn-capable-rtp" attribute, 

NOTE 2: Only the "leap" initialisation method is supported over the Ix interface in this release. 

the IBCF shall: 

act as an end point for ECN; 

select an initialisation method supported by the TrGW; 

determine if application specific feedback or ECN feedback messages shall be used, taking into account whether 
the TrGW supports ECN feedback messages, and the negotiation procedures in 3GPP TS 26. 1 14 [36]; 

determine if ECN XR summary reports can be used, taking into account whether they are supported at the TrGW 
and the negotiation procedures in 3GPP TS 26.1 14 [36]; 

send an SDP answer according to 3GPP TS 26.1 14 [36] and the capabilities of the TrGW, containing the "a=ecn- 
capable-rtp" attribute; and 

indicate to the TrGW that it shall apply the ECN procedures (according to 3GPP TS 26. 1 14 [36]) and act as an 
ECT endpoint. 

The TrGW should not send RTCP XR ECN summary reports. 

1 0.2.1 3.3 Incoming SDP offer without ECN 

If the IBCF receives an SDP offer without the "a=ecn-capable-rtp" attribute then if all of the following statements are 
true: 

a) the IBCF supports ECN according to 3GPP TS 26.1 14 [36]; 

b) the TrGW supports ECN according to 3GPP TS 26.1 14 [36]; and 

c) the IBCF knows (via configuration) that the succeeding network supports ECN according to 3GPP TS 26.1 14 
[36]; 
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the IBCF may include the "a=ecn-capable-rtp" attribute in the SDP offer it forwards towards the succeeding node, 
indicating the related capabilities of the TrGW. 

NOTE: ECN XR summary reports and RTCP AVPF ECN feedback message are not supported in this release 
towards IMS terminations. 

If the IBCF inserted ECN attributes in the SDP offer and receives an SDP answer containing the "a=ecn-capable-rtp" 
attribute the IBCF shall act as an endpoint and shall return the SDP answer to the preceding node removing the "a=ecn- 
capable-rtp" attribute, any "rtcp-fb" attribute with the "nack" feedback parameter and the "ecn" feedback parameter 
value, and any "ecn-sum" parameter within a "rtcp-xr" attribute, and shall indicate to the TrGW that it shall apply the 
ECN procedures according to 3GPP TS 26.1 14 [36] and act as an ECT endpoint. The TrGW should not send RTCP XR 
ECN summary reports. 

If the IBCF inserted the "a=ecn-capable-rtp" attribute in the SDP offer and receives an SDP answer without the "a=ecn- 
capable-rtp" attribute the IBCF shall continue the call without any ECN active. 

1 0.2.1 3.3a Detection of ECN failures by TrGW 

If the TrGW acts as ECN endpoint and detects an ECN-related error case, for example non-ECT in the received packets 
when ECT(O) was expected or detecting a very high packet loss rate when ECN is used, the TrGW shall notify the 
IBCF. The IBCF should then initiate a session re-negotiation to disable ECN. 

1 0.2.1 3.4 Interworking with non-3GPP EON IP terminal 

10.2.13.4.1 Support for additional ECN parameters 

An IBCF and TrGW may support additional ECN parameter settings than defined in 10.2.13.2. The following sub- 
clauses describe the optional behaviour if the IBCF and TrGW support these additional values. 

10.2.13.4.2 Incoming SDP offer from external IP network with ECN 

If the IBCF receives an incoming SDP offer from the external IP network containing values in the incoming SDP offer 
not supported by MTSI then it shall configure the SDP offer as defined in subclause 10.2.13.2 when forwarding the 
SDP offer to the IMS. 

When receiving the SDP answer from the IMS the IBCF may configure the SDP answer to the external IP network with 
alternative settings depending on what is received from the IMS and what was offered by the external IP network. The 
permitted alternatives are listed in table 10.2.13.4.1; the supported alternatives are implementation options which need 
to be derived through configuration or package auditing. 

10.2.13.4.3 Incoming SDP offer from the IMS with ECN 

If the IBCF receives an incoming SDP offer from the IMS and it supports additional ECN parameter settings than those 
defined in subclause 10.2.13.2 the IBCF may add these to the SDP offer forwarded to the external IP network. 

When receiving an SDP answer from the external IP network the IBCF shall respond to the IMS in accordance with 
10.2.13.2. If the IBCF modifies any ECN-related parameters in the forwarded SDP answer compared to the received 
SDP answer, the IBCF shall configure its TrGW as an ECN endpoint. The permitted alternatives are listed in table 
10.2.13.4.1; the supported alternatives are implementation options which need to be derived through configuration or 
package auditing. 
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Table 10.2.13.4.1 : Possible configurations when interworking with non-3GPP ECN IP terminal 



ECN SDP Attribute and required TrGW Action 


IMS side 


External IP 
Network 


TrGW Action 


Initiation 




"leap" 


"rtp" 
NOTES 


Act as an Endpoint and trigger explicit initiation using RTP and RTCP as 
described in IETF RFC 6679 [38] toward the external IP network. When initial 
ECT marked packets are received from the external IP network these are 
forwarded to the IIVIS (all packets shall be marked) and early feedback and XR 
Summary reports are sent back to the external IP network. If ECT marked 
packets are received from the IIVIS before any initiation is completed with the 
external IP network then ECT marking should be removed and only a fraction of 
the packets should be marked until feedfback is received from the external IP 
network. 


"ice" 


This initiation method is not supported in the present release. 


IVIode 




"setread" 


"readonly" 


Act as ECN transparent unless required to act as an Endpoint for other reasons 
but mark packets toward the IMS with ECT(O). If ECN-CE is received from the 
IMS then this shall be handled by the IMS termination as currently specified for 
the non-interworking case and not forwarded to the external IP network. 


"setonly" 


Act as ECN transparent (unless required to act as ECN Endpoint for other 
reasons) - ECN-CE marked packets will not be received from external IP 
network, ECN-CE marked packets from the IMS will be passed to the external 
IP network. 


ECT 




"ect(O)" 


"ect(1 )" 


Act as ECN transparent unless required to act as an Endpoint for other reasons 
but mark packets toward the IMS with ECT(O) and mark packets toward external 
network with ECT(1). 


"random" 


Act as ECN transparent unless required to act as an Endpoint for other reasons 
but mark packets toward IMS with ECT(O). Packets received from the IMS are 
left as ECT(O). 


RTCP feedback 




no "rtcp- 
fb:* nack 
ecn" 

(received 

driven 

congestion 

control) 


"rtcp-fb:* nack 
ecn " (sender 
driven 
congestion 
control) 


For AMR, the handling of an AVPF feedback message received from the 
external IP the handling is not defined. 

For video related AVFP feedback messages received from the external IP 
network the TrGW shall generate the appropriate TMBR request towards the 
IMS. If a TMBR request is received from the IMS the TrGW shall generate an 
appropriate AVPF feedback message to the external IP network. 


"rtcp-fb:* 
nack ecn" 

(sender 

driven 

congestion 

control) 


rtcp-fb:* nack 
ecn" (sender 
driven 
congestion 
control) 


An AVPF feedback message received from the external IP network shall be 
forwarded via the IMS termination. 


RTCP XR ECN summary 
report 




- 


"rtcp-xr:ecn-sum" 


RTCP XR is not bi-directions and each end-point indicates whetever XR 
feedback it supports. Hence, if the SDP offer does not contain rtcp-xr with "ecn- 
sum" then it can still be added in the SDP answer. 

The TrGW shall include XR ECN Summary reports towards the external IP 
network and receive reports from the external IP network. (NOTE 4) 


N0TE1 : The settings for IMS side may be supported on the External IP Network side in which case no 

interworking is specified. 
NOTE 2: Each parameter is described separately as each parameter may or may not need to be interworked. 

Unless stated otherwise the assumption is that each parameter can be treated independently. 
NOTE 3: RTCP feedback messages need to be supported and negotiated for the "rtp" initialisation method 
NOTE 4: The contents of the XR reports will be limited to data received from the external IP network. 



£75/ 



3GPP TS 29.162 version 10.7.0 Release 10 



36 



ETSI TS 129 162 VI 0.7.0 (2013-01) 



1 0.2.1 3.5 Message sequence chart 

10.2.13.5.1 ECN support requested (ECN endpoint) 

Figure 10.2.13.5.1.1 shows the message sequence chart example for requesting ECN. 



IBCF 



Context(Cx; 
Context(Cx; 



TrGW 



H.248:ADD.req[ 

Termination X, 

Transport = RTP/AVPF, 

ECIM_enable=True, 

{Notify_ECN_Error}] 



H.248:ADD.resp[Termination X] 



Reserve IMS 

Connection Point and 

Configure Remote 

Resources 



Figure 10.2.13.5.1.1: Procedure to Request ECN 

Upon receipt of a request to apply ECN the TrGW shall set the ECN field of the IP header in accordance with 3GPP TS 
26.1 14 [36] when sending any data packets. 

Upon receipt of any IP headers indicating ECN Congestion Experienced (ECN-CE) the TrGW shall trigger rate 
adaptation in accordance with 3GPP TS 26.1 14 [36]. 

NOTE: ECN requires the IBCF to configure the TrGW with all media attributes to allow rate adaptation even if 
no transcoding is required/supported in the TrGW. 

10.2.13.5.2 ECN Active Indicated (ECN transparent) 

Figure 10.2.13.5.2.1 shows the message sequence chart example for indicating ECN transparent. 



IBCF 



Context(Cx; 
Context(Cx; 



TrGW 



H.248:ADD.req[ 

Termination X, 

Transport = RTP/AVPF, 

ECN_enable = True, 

lnitialisation_Metliod = Inactive] 



H.248:ADD.resp[Termination X] 



Reserve IMS 

Connection Point and 

Configure Remote 

Resources 



Figure 10.2.13.5.2.1 : Procedure to indicate ECN transparent negotiated 

Upon receipt of the indication that ECN transparent has been negotiated the TrGW shall forward IP packets with ECN 
bits set unmodified. 
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10.2.13.5.3 ECN Failure Indication (ECN endpoint) 

Figure 10.2.13.5.3.1 shows the message sequence chart example for an ECN Failure Event. 



IBCF 



Context(Cx; 
Context(Cx; 



TrGW 



H.248:NOTIFY.req(ECN Failure) 
[Termination =x, cause=ecn_cause] 



H.248:NOTiFY.resp(ECN Faiiure) 
[Termination x] 



Report ECN Failure 



Figure 10.2.13.5.3.1: Procedure to Report ECN Failure 

When the IBCF receives a Notification indicating that a failure has occurred, the MGCF may trigger a new SDP offer to 
disable ECN. 

10.2.14 Optimal Media Routeing 

An IBCF may support optimal media routeing (OMR) procedures, as defined in 3GPP TS 29.079 [39]. 

3GPP TS 29.079 [39] specifies that "secondary media resources" may be allocated in addition to "primary media 
resources". If cotrolled by an IBCF, such primary or secondary media resources are TrGWs controlled over the Ix 
interface with procedures specified in the present specification. 

If the IBCF applies OMR procedures, the following modifications to the procedures within the present specification are 
apphcable: 

- Under conditions specified in 3GPP TS 29.079 [39], the IBCF uses information from OMR related SDP 
attributes as remote connection and port information that is provided towards the TrGW within the call 
establishment procedures in subclause 10.1.3.1.1. 

Under conditions specified in 3GPP TS 29.079 [39], the IBCF encapsulates local addess and port information, as 
received from the TrGW within the call establishment procedures in subclause 10.1.3.1.1, in OMR related SDP 
attributes. 

- Under conditions specified in 3GPP TS 29.079 [39], the IBCF uses information from OMR related SDP 
attributes as codec information that is provided towards the TrGW within the media control procedures in clause 
10.2.5. 

3GPP TS 29.079 [39] specifies OMR-specific events that trigger the call release procedures in subclause 
10.1.3.1.2. 

1 0.2.1 5 IP Realm Availability 

The procedures in subclause A.7.1.2.2.5 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.1 6 Access Transfer procedures with media anchored in ATGW 

The procedures in the present clause are optional to be supported for both IBCF and TrGW when supporting the ATCF 
and ATGW functionality (see subclause 6.1.4). 
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The procedures in subclause 6.2.14 of 3GPP TS 23.334 [43] are applicable, except that where the Iq interface is 
mentioned in those procedures, the Ix interface is applicable. 

10.3 Void 

10.4 Procedures 

10.4.1 Call related Procedures 

1 0.4.1 .1 Reserve TrGW Connection Point 

This procedure is used to reserve an termination at the TrGW. 
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Table 10.4.1.1.1 : Reserve TrGW Connection Point 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Reserve TrGW 


IBCF 


Context/Context 


M 


This information element indicates the 


Connection Point 




Request 




existing context or requests a new 
context for the bearer termination. 


Emergency Call 





This information element identifies the 






Indicator 




call as emergency call that requires a 
preferential handling. 


Termination 


M 


This information element requests a new 






Request 




termination for the bearer to be 
established. 


IP Interface 





This information element specifies the 










type of external interface to be used for 










the IP termination (e.g. MbolP). 


Local IP Resources 





This information element indicates the 










resource{s) (e.g. codec, auxiliary payload 










types) for which the TrGW shall be 










prepared to receive user data. IVIay be 










excluded (i.e. "-" is used in SDP m-line) if 










no transcoding or other media related 










functions are required. 


ReserveValue 


C 


This information element indicates if 










multiple local resources are to be 










reserved. 










This information element shall be 










included if a speech codec and auxiliary 










payload types are configured. 


Local Connection 


M 


This information element requests an IP 






Address Request 




address and port number on the TrGW 
that the remote end can send user plane 
data to. 


Remote Source 





This information element indicates that 






Address Filtering 




remote source address filtering is 
required. 


Remote Source 


C 


This information element provides 






Address IVIask 




information on the valid remote source 
addresses. This may be included if 
remote source address filtering is 
included. It shall not be included if 
remote source address filtering is not 
included. 


Remote Source 





This information element indicates that 






Port Filtering 




remote source port filtering is required. 


Remote Source 


C 


This information element identifies the 






Port 




valid remote source port. This may be 
included if remote source port filtering is 
included. It shall not be included if 
remote source port filtering is not 
included. (N0TE1) 


Remote Source 


C 


This information element identifies a 






Port Range 




range of valid remote source ports. This 
may be included if remote source port 
filtering is included. It shall not be 
included if remote source port filtering is 
not included. (NOTE 1) 


RTCP handling 





Indicates whether or not the TrGW shall 










reserve a port for an RTCP flow. 


Notify termination 


M 


This information element requests 






heartbeat 




termination heartbeat indications. 


Notify Released 





This information element requests a 






Bearer 




notification of a released bearer. 
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DiffServ Code Point 



DiffServ Tagging 
Betiaviour 



IP Realm Identifier 



Traffic Policing 
Required 



Peak Data Rate 



Sustainable Data 
Rate 



Delay Variation 
Tolerance 



Maximum Burst 
Size 



IVIedia Inactivity 
Detection Required 



Inactivity Detection 
Time 



Inactivity Detection 
Direction 



ECN Enable 



ECN Initiation 
Method 



Congestion 
Response Method 



ECN ECT Marking 



ECN Mode 



RTCP Feedback 



O 



O 



O 



O 



O 



O 



O 



O 



O 



This information element indicates a 
specific DiffServ code point to be used in 
the IP header in packets sent on the IP 
termination. 



This information element indicates 
whether the Diffserv code point in thelP 
header in packets sent on the IP 
termination should be copied from the 
received value or set to a specific value. 



This information element indicates the IP 
realm of the IP termination. 



This information element indicates that 
policing of the media flow is required. 



This information element may be present 
if Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 2) 



This information element may be present 
if Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 2) 



This information element may be present 
if Policing on Peak Data Rate is required 
and specifies the maximum expected 
delay variation tolerance for the 
corresponding media stream. 



This information element shall be present 
if Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the 
corresponding media stream. 



This information element indicates that 
detection of inactive media flows is 
required. 



This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
time. 



This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
direction. 



This information element requests the 
TrGW to apply ECN procedures 



This information element specifies the 
ECN Initiation method and requests the 
TrGW to perform IP header settings as 
an ECN endpoint, or indicates that ECN 
bits shall be passed transparently. It may 
be included only if ECN is enabled. 



This information element specifies the 
ECN Congestion Response Method; 
receiver driven or sender driven. The 
default is "received driven congestion 
control". It may be included only if ECN is 
enabled and the TrGW acts as ECN 
endpoint. (NOTE 3) 



This information element specifies the 
ECN ECT Marking. It may be included 
only if ECN is enabled and the TrGW 
acts as ECN endpoint. (NOTE 3) 



This information element specifies the 
ECN Mode. It may be included only if 
ECN is enabled and the TrGW acts as 
ECN endpoint. (NOTE 3) 



This information element specifies the 
RTCP Feedback support. (NOTE 3) 
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XR Summary 
Report 


C 


This information element specifies the 
support of XR Summary Reporting. 


Notify ECN Failure 
Event 


C 


This information element requests a 
notification if a ECN failure occurs. It may 
only be supplied if ECN is enabled and 
the TrGW acts as ECN endpoint. 


Reserve TrGW 

Connection Point 

Ack 


TrGW 


Context 


M 


This information element indicates the 
context where the command was 
executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 


Local IP Resources 


C 


This information element indicates the 
resources that the TrGW has reserved to 
receive the user plane data from the 
remote peer. This information element 
shall be present if it was contained in the 
request. If the information element was 
not contained in the request, it may be 
present in the reply. 


Local Connection 
Address 


M 


This information element indicates the IP 
address and port on the TrGW that shall 
receive user plane data from the remote 
peer. 


NOTE 1 : Remote Source Port and Remote Source Port Range are mutually exclusive. 
NOTE 2: At least one of these information elementssliall be present when policing is required. 
NOTE 3: This parameter does not need to be signalled if support is for 3GPP defined ECN only. 



1 0.4.1 .2 Configure TrGW Connection Point 

This procedure is used to configure or reconfigure an termination at the TrGW. 
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Table 10.4.1.2.1 : Configure TrGW Connection Point Procedure 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Configure TrGW 


IBCF 


Context 


M 


This information element indicates the 


Connection Point 








existing context. 


Termination 


M 


This information element indicates the 










existing bearer termination. 


IP Interface 





This information element specifies the 










type of external interface to be used for 










the IP termination (e.g. MbolP). 


Local IP Resources 





This information element indicates the 










resources (e.g. codec, auxiliary payload 










types) that the TrGW may use on the 










reception of user plane data. 










If Local Connection Address is supplied 










may be excluded (i.e. "-" is used in SDP 










m-line) if no transcoding or other media 










related functions are required. 


Remote IP 





This information element indicates the 






Resources 




resources (e.g. codec, auxiliary payload 
types) that the TrGW may send user 
plane data to. 

If Remote Connection Address is 
supplied may be excluded (i.e. "-" is used 
in SDP m-line) if no transcoding or other 
media related functions are required. 


Local Connection 





This information element indicates the IP 






Address 




address and port on the TrGW that the 
remote peer can send user plane data to. 


Remote 





This information element indicates the IP 






Connection 




address and port that the TrGW can 






Address 




send user plane data to. 


Reserve Value 


C 


This information element indicates if 










multiple resources are to be reserved. 










This information element shall be 










included if a speech codec and auxiliary 










payload types are configured. 


Remote Source 





This information element indicates that 






Address Filtering 




remote source address filtering is 
required. 


Remote Source 


C 


This information element provides 






Address IVIask 




information on the valid remote source 
addresses. This may be included if 
remote source address filtering is 
included. It shall not be included if 
remote source address filtering is not 
included. 


Remote Source 





This information element Indicates that 






Port Filtering 




remote source port filtering is required. 


Remote Source 


C 


This information element identifies the 






Port 




valid remote source port. This may be 
included if remote source port filtering is 
included. It shall not be included if 
remote source port filtering is not 
included. (N0TE1) 


Remote Source 


C 


This information element identifies a 






Port Range 




range of valid remote source ports. This 
may be included if remote source port 
filtering is included. It shall not be 
included if remote source port filtering is 
not included. (NOTE 1) 


RTCP handling 





Indicates whether or not the TrGW shall 










reserve a port for an RTCP flow 


Traffic Policing 





This information element indicates that 






Required 




policing of the media flow is required. 
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Peak Data Rate 





This information element may be present 
if Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 2) 


Sustainable Data 
Rate 





This information element may be present 
if Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 2) 


Delay Variation 
Tolerance 





This information element may be present 
if Policing on Peak Data Rate is required 
and specifies the maximum expected 
delay variation tolerance for the 
corresponding media stream. 


Maximum Burst 
Size 


C 


This information element shall be present 
if Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the 
corresponding media stream. 


DiffServ Code Point 





This information element indicates a 
specific DiffServ code point to be used in 
the IP header in packets sent on the IP 
termination. 


DiffServ Tagging 
Behaviour 





This information element indicates 
whether the Diffserv code point in thelP 
header in packets sent on the IP 
termination should be copied from the 
received value or set to a specific value. 


Media Inactivity 
Detection Required 





This information element indicates that 
detection of inactive media flows is 
required. 


Inactivity Detection 
Time 


C 


This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
time. 


Inactivity Detection 
Direction 


C 


This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
direction. 


ECN Enable 





This information element requests the 
TrGW to apply ECN procedures. 


ECN Initiation 
Method 


C 


This information element specifies the 
ECN Initiation method and requests the 
TrGW to perform IP header settings as 
an ECN endpoint, or indicates that ECN 
bits shall be passed transparently. It may 
be included only if ECN is enabled. 


Congestion 
Response Method 


C 


This information element specifies the 
ECN Congestion Response Method; 
receiver driven or sender driven. The 
default is "received driven congestion 
control". It may be included only if ECN is 
enabled and the TrGW acts as ECN 
endpoint. (NOTE 3) 


ECN ECT Marking 


C 


This information element specifies the 
ECN ECT Marking. It may be included 
only if ECN is enabled and the TrGW 
acts as ECN endpoint. (NOTE 3) 


ECN Mode 


C 


This information element specifies the 
ECN Mode. It may be included only if 
ECN is enabled and the TrGW acts as 
ECN endpoint. (NOTE 3) 


RTCP Feedback 


C 


This information element specifies the 
RTCP Feedback support. (NOTE 3) 


XR Summary 
Report 


C 


This information element specifies the 
support of XR Summary Reporting. 
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Notify ECN Failure 
Event 


C 


This information element requests a 
notification if a ECN failure occurs. It 
mayonly be supplied if ECN is enabled 
and the TrGW acts as ECN endpoint. 


Configure TrGW 
Connection Point 
Acl< 


TrGW 


Context 


M 


This information element indicates the 
context where the command was 
executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 


Local IP Resources 





This information element indicates the 
resources that the TrGW has reserved to 
receive the user plane data from the far 
end. 


Remote IP 
Resources 





This information element indicates the 
resource (i.e. codec) that the TrGW shall 
use to send user data to. May be present 
only if corresponding information 
elementis present in the request. 


Local Connection 
Address 





This information element indicates the IP 
address and port on the TrGW that the 
remote end can send user plane data to. 


Remote 

Connection 

Address 





This information element indicates the IP 
address and port that the TrGW can 
send user plane data to. May be present 
only if corresponding information element 
is present in the request. 


NOTE 1 : Remote Source Port and Remote Source Port Range are mutually exclusive. 
NOTE 2: At least one of these information elementsshall be present when policing is required. 
NOTE 3: This parameter does not need to be signalled if support is for 3GPP defined ECN only. 



1 0.4.1 .3 Reserve and Configure TrGW Connection Point 

This procedure is used to reserve and configure multimedia-processing resources for a termination at the TrGW. 
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Table 10.4.1.3.1 : Reserve and Configure TrGW Connection Point 



Procedure 


initiated 


Information element 
name 


information 
element 
required 


information element description 


Reserve and 


IBCF 


Context/Context 


M 


This information element indicates the 


Configure TrGW 




Request 




existing context or requests a new context 


Connection Point 








for the bearer termination. 


Emergency Call 





This information element identifies the call 






Indicator 




as emergency call that requires a 
preferential handling. 


Termination/ 


M 


This information element indicates the 






Termination Request 




existing bearer termination or requests a 
new termination for the bearer to be 
established. 


IP Interface 





This information element specifies the used 










interface type for the IP termination (e.g. 










MbolP). 


Local IP Resources 


C 


This information element indicates the 










resource{s) (e.g. codec, auxiliary payload 










types) for which the TrGW shall be prepared 










to receive user data May be excluded (i.e. "- 










" is used in SDP m-line) if no transcoding or 










other media related functions are required. 


Remote IP Resources 


C 


This information element indicates the 










resources (e.g. codec, auxiliary payload 










types) that the TrGW shall use to send user 










data. May be excluded (i.e. "-" is used in 










SDP m-line) if no transcoding or other media 










related functions are required. 


Reserve Value 


C 


This information element indicates if multiple 










IP resources are to be reserved. This 










information element shall be included if a 










speech codec and auxiliary payload types 










are configured. 


Local Connection 


M 


This information element requests an IP 






Address request 




address and a port number on the TrGW 
that the remote end can send user plane 
data to. 


Remote Connection 


M 


This information element indicates the IP 






Address 




address and ports of the remote party that 
the TrGW can send user plane data to. 


Remote Source 





This information element indicates that 






Address Filtering 




remote source address filtering is required. 


Remote Source 


C 


This information element provides 






Address IVIask 




information on the valid remote source 
addresses. This may be included if remote 
source address filtering is included. It shall 
not be included if remote source address 
filtering is not included. 


Remote Source Port 





This information element indicates that 






Filtering 




remote source port filtering is required. 


Remote Source Port 


C 


This information element identifies the valid 










remote source port. This may be included if 










remote source port filtering is included. It 










shall not be included if remote source port 










filtering is not included. (NOTE 1) 


Remote Source Port 


C 


This information element identifies a range 






Range 




of valid remote source ports. This may be 
included if remote source port filtering is 
included. It shall not be included if remote 
source port filtering is not included. (NOTE 
1) 


RTCP handling 





This information element indicates whether 










or not the TrGW shall reserve a port for an 










RTCP flow. 
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Notify termination 
heartbeat 



Notify Released 
Bearer 



IP Realm Identifier 



Traffic Policing 
Required 



Peak Data Rate 



Sustainable Data 
Rate 



Delay Variation 
Tolerance 



IVIaximum Burst Size 



DiffServ Code Point 



DiffServ Tagging 
Behaviour 



Media Inactivity 
Detection Required 



Inactivity Detection 
Time 



Inactivity Detection 
Direction 



ECN Enable 



ECN Initiation IVIethod 



Congestion 
Response Method 



ECN ECT Marking 



ECN Mode 



RTCP Feedback 



M 



O 



O 



O 



O 



O 



O 



O 



O 



O 



O 



This information element requests 
termination heartbeat indications. 



This information element requests a 
notification of a released bearer. 



This information element indicates the IP 
realm of the IP termination. 



This information element indicates that 
policing of the media flow is required. 



This information element may be present if 
Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 2) 



This information element may be present if 
Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 2) 



This information element may be present if 
Policing on Peak Data Rate is required and 
specifies the maximum expected delay 
variation tolerance for the corresponding 
media stream. 



This information element shall be present if 
Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the corresponding 
media stream. 



This information element indicates a specific 
DiffServ code point to be used in the IP 
header in packets sent on the IP 
termination. 



This information element indicates whether 
the Diffserv code point in thelP header in 
packets sent on the IP termination should be 
copied from the received value or set to a 
specific value. 



This information element indicates that 
detection of inactive media flows is required. 



This information element may be present if 
Inactive Media Detection is required and 
specifies the Inactivity Detection time. 



This information element may be present if 
Inactive Media Detection is required and 
specifies the Inactivity Detection direction. 



This information element requests the TrGW 
to apply ECN procedures. 



This information element specifies the ECN 
Initiation method and requests the TrGW to 
perform IP header settings as an ECN 
endpoint, or indicates that ECN bits shall be 
passed transparently. It may be included 
only if ECN is enabled. 



This information element specifies the ECN 
Congestion Response Method; receiver 
driven or sender driven. The default is 
"received driven congestion control". It may 
be included only if ECN is enabled and the 
TrGW acts as ECN endpoint. (NOTE 3) 



This information element specifies the ECN 
ECT Marking. It may be included only if ECN 
is enabled and the TrGW acts as ECN 
endpoint. (NOTE 3) 



This information element specifies the ECN 
Mode. It may be included only if ECN is 
enabled and the TrGW acts as ECN 
endpoint. (NOTE 3) 



This information element specifies the RTCP 
Feedback support. (NOTE 3) 
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XR Summary Report 


C 


This information element specifies the 
support of XR Summary Reporting. 


Notify ECN 
Failure Event 


C 


This information element requests a 
notification if a ECN failure occurs due to 
ECN. It mayonly be supplied if ECN is 
enabled and the TrGW acts as ECN 
endpoint. 


Reserve and 

Configure TrGW 

Connection Point 

Acl< 


TrGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 


Local IP Resources 


C 


This information element indicates the 
resources that the TrGW has reserved to 
receive the user plane data from the remote 
side. This information element shall be 
present if it was contained in the request. 
If the information element was not contained 
in the request, it may be present in the reply. 


Remote IP Resources 





This information element indicates the 
resource (i.e. codec) that the TrGW shall 
use to send user data. 


Local Connection 
Addresses 


M 


This information element indicates the IP 
address and port on the TrGW that shall 
receive user plane data. 


Remote Connection 
Address 





This information element indicates the IP 
address and port that the TrGW can send 
user plane data to. 


NOTE 1 : Remote Source Port and Remote Source Port Range are mutually exclusive. 
NOTE 2: At least one of these information elements shall be present when policing is required. 
NOTE 3: This parameter does not need to be signalled if support is for 3GPP defined ECN only. 



1 0.4.1 .4 Release TrGW Termination 

This procedure is used to release multimedia-processing resources for a termination at the TrGW. 

Table 10.4.1.4.1: Release TrGW Termination 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Release TrGW 
Termination 


IBCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
existing bearer termination to be 
released. 


Release TrGW 

Termination 

Ack 


TrGW 


Context 


M 


This information element indicates the 
context where the command was 
executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



NOTE: No requirement for statistics in the Release TrGW Termination Ack has been justified by a use case. 
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10.4.1.5 



IP Bearer Released 



Table 10.4.1.5.1: IP Bearer Released 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


IP Bearer 
Released 


TrGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Termination 


M 


This information element indicates the bearer 
termination where the bearer was released. 


Bearer Released 


M 


This information element notifies a bearer 
release. 


Release Cause 


M 


This information element indicates the cause 
of a bearer release. 


IP Bearer 
Released Ack 


IBCF 


Context 


M 


This information element indicates all context 
are where the command was executed. 


Termination 


M 


This information element indicates that 
Bearer termination is where the command 
was executed. 



10.4.1 .6 Media Inactivity Detection 

This command is used to notify the IBCF of media inactivity on the TrGW. 

Table 10.4.1.6.1: Media Inactivity Notification 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Media Inactivity 
Notification 


TrGW 


Context 


M 


This information element indicates the 
existing context for the bearer termination. 


Termination 


M 


This information element indicates that 
bearer termination is where the media 
inactivity detection was activated. 


Media Inactivity 


M 


This information element notifies the IBCF of 
Media inactivity detection on the bearer 
termination. 


Media Inactivity 
Notification Ack 


IBCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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10.4.1 .7 Termination heartbeat indication 

This command is used by the TrGW to periodically notify the IBCF of a termination heartbeat. 

Table 10.4.1.7.1: Termination heartbeat indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Termination 
heartbeat 
indication 


TrGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination for which the termination 
heartbeat is reported. 


Termination heartbeat 


M 


Hanging Termination event. 


Termination 

heartbeat 

indication Ack 


IBCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



1 0.4.1 .8 Change Through-Connection 

This procedure is used to change the Through-connection in the bearer termination. 

Table 10.4.1.8.1: Change Through-Connection 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Change Through- 
Connection 


IBCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context for 
the bearer termination. 


Bearer 

Termination/Bearer 

Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a new 
Bearer termination where the through 
connection is changed. 


Through-Connection 


M 


This information element indicates the 
through-connection of the bearer termination. 


Change Through- 
Connection Ack 


TrGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



NOTE: This procedure may be combined with Reserve and Configure TrGW Connection Point, Reserve TrGW 
Connection Point or Configure TrGW Connection Point procedure. This list of procedures is not 
exhaustive. 
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10.4.1.9 ECN Failure Indication 

This procedure is used to report ECN related failures (see clause 10.2.13.3a). 

Table 10.4.1.9.1: Procedures toward the IM Subsystem: ECN Failure Indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


ECN Error 
Indication 


TrGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
bearer termination for which the ECN failure 
is reported. 


ECN Error Indication 


M 


This information element indicates an ECN 
failure event. 


ECN Error 
Indication Ack 


IBCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the 
bearer termination where the command was 
executed. 



10.4.1.10 Change Flow Direction 

This procedure may be used to change the flow direction between bearer terminations within a context for access 
transfer procedures (see Clause 10.2.15). 

Table 10.4.1.10.1 : Procedures toward the IM Subsystem: Change Flow Direction 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Change Flow 
Direction 


IBCF(ATCF) 


Context/Context 
Request 


M 


This information element indicates the 
existing context or a new context where the 
flow direction is changed. 


Bearer Termination 1/ 

Bearer Termination 1 

Request 


M 


This information element indicates the 
existing bearer termination or a new bearer 
termination from where the new flow direction 
is applied. 


Bearer Termination 2/ 

Bearer Termination 2 

Request 


M 


This information element indicates the 
existing bearer termination or a new bearer 
termination where to the new flow direction is 
applied. 


Flow Direction 


M 


This information element indicates the flow 
direction from the bearer termination 1 to 
bearer termination 2 within the context. 


Change Flow 
Direction Ack 


TrGW(ATGW 
) 


Context 


M 


This information element indicates the 
context where the command was executed. 



10.4.2 Non Call related Procedures 

The procedures in table 10.4.2.1 shall be applied between the IBCF and TrGW. 
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Table 10.4.2.1: Non-call related procedures 



Stage 3 Procedure (for information) 

defined in 

3GPP TS 29.238 [25] 


Corresponding Stage 2 Procedure 

defined in 

3GPP TS 23.205 [28] 


Remarks 


TrGW Out of service 


IVIGW Out of Service 




TrGW Communication Up 


IVIGW Communication Up 




TrGW Restoration 


IVIGW Restoration 




TrGW Register 


IVIGW Register 




TrGW Re-register 


IVIGW Re-register 




CS-IBCF Ordered Re-register 


(G)IVISC Server Ordered Re-register 




CS-IBCF Restoration 


(G)IVISC Server Restoration 




CS-IBCF Out of Service 


(G)MSC Server Out of Service 




Termination Out-of-Service 


Termination Out-of-Service 


The "Termination Out-of-Service 
procedure" is also used as a call- 
related H.248 command 


Audit Value 


Audit Value 




Command Rejected 


Command Rejected 


The "Command Rejected" procedure 
may be used in response both to 
call-related and non-call-related 
H.248 commands. 


TrGW Capability Change 


Capability Update 




TrGW Resource Congestion Handling 
- Activate 


IVIGW Resource Congestion 
Handling -Activate 




TrGW Resource Congestion Handling 
- Indication 


IVIGW Resource Congestion 
Handling - Indication 




Inactivity timeout activation 


Inactivity timeout activation 




Inactivity timeout indication 


Inactivity timeout indication 




Realm Availability Change Activation 




See 3GPP TS 29.235 [29] subclause 
A.7.2 


Realm Availability Change Indication 




See 3GPP TS 29.235 [29] subclause 
A.7.2 
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Annex A (informative): 
Void. 
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Annex B (informative): 
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